Data Source Management

Data source management can be divided into 2 main aspects: data source setup; and management of user access to data source servers, databases, data models and all related elements.

Data sources must be setup up by an Admin from the Data Sources page. Apart from providing a convenient mechanism to add new data sources for end users (who don't need to handle all the complexities of setting up a data source), it also provides the main mechanism for governing who can see which data source (by role) and who will be able to write-back and build models into the data source where possible.

Once the materialized data artifacts have been created, admins can continue to administer and adjust these security settings through the Data Source Manager while model owners can administer the same security settings through the Materialized Data Manager - albeit with less scope and functionality.

The Data Source Manager is where admins manage user access to data source servers, databases, data models and all related elements. This is also where admins can edit metadata overlays within data models, enabling them to ensure that the data is named and described to each user role in the required way. As security and metadata is role-based, the admin simply needs to assign the relevant roles to the selected items.

Data Sources

Admins configure and manage data sources from the Admin Console. To connect to a data source in Model, it must first be configured by the Admin.

  • Click here to learn about data source configuration.

Data Source Manager

Metadata security and overlays can be governed from the Data Source Manager in the Admin console, where administrators can manage database and data model security, as well as hierarchy, measure, and member security and overlays, using role level security. The permissions set here determine which roles will have access to the database and/ or data model in Discover.

These permissions may differ from the security permissions that were set from within Model. If this is the case, then any time the data model is processed, the security permissions set from within the model definition file will override the permissions set in the Admin console, unless Override Security is disabled from the Processing Options dialog. When the Override Security option is enabled, security set at the database and data model levels are overridden. Hierarchy, measure, member, and level security is not affected.

For instance, if Role 1 is granted read and write permissions from within the model definition file, then only Role 1 will have access to the materialized model in Discover. However, if Role 2 is then granted read and write permissions from the Admin console, or from the materialized manager, then both Role 1 and 2 will have read and write access to the model in Discover. If the data model is processed again, and Override Security is enabled, then Role 2 will no longer have access to the database and data model.

Metadata Overlays

Metadata overlays can be edited from the Data Source Manager; Admins can edit overlays for hierarchies, measures, and levels.

Hierarchies

Columns in the data model are referred to as 'hierarchies' in Pyramid. Admins can edit hierarchy overlays to adjust a hierarchy's metadata for a specific roles. This includes the hierarchy display folder, description, name, and type. Each of these types of metadata can be edited for specified roles, enabling admins to determine how hierarchies are presented to different user roles.

For instance, you could create an overlay with American spelling for US user roles. This way users in the UK will see British spelling, while users in the US will see American spelling.

  • Click here to learn about hierarchy overlays.
Measures

Measure overlays allow admins to adjust a measure's metadata for specified roles. This includes the display measure's folder name, measure description, measure name, and format string. Each of these fields can be edited, and users will see the edited version (overlay) that was configured for their role specifically, rather than the metadata that exists in the data model.

  • Click here to learn about measure overlays.
Levels

In Model, users can construct multi-level hierarchies; level overlays allow admins to edit the metadata of levels in a multi-level hierarchy for specified roles. Admins can edit the level description, name, and type for any given roles.

  • Click here to learn about level overlays.

Metadata Security

By default, all roles assigned to the data model can see all of its contents: all columns (known in Pyramid as hierarchies), measures, and attributes (knows in Pyramid as member elements).

Admins can set role security on specified hierarchies, measures, and member elements in a given data model. This allows admins to determine which roles should and shouldn't SEE specified hierarchies, measures, or members in the data model, which is an important aspect of governance.

Member security can be either static (based on static selections) or dynamic (based on a PQL script).

  • Click here to learn about settings security for hierarchies.
  • Click here to learn about measure security.
  • Click here to learn about member security.